I think this all belongs in the Zend\Mvc\Service location.

@ralphschindler
yes this is a better place for "AdapterManagerFactory" ... you think move both?

Yes, I think both should be moved, they are only useful in an MVC application that consumes the ServiceManager (as described since both of these have dependencies on the ServiceManager).

Two additional notes:

• Needs unit tests! :)
• Also, Zend\Db\Adapter\AdapterServiceFactory already uses the "db" key, which means that we could end up with a configuration conflict. I think the top-level configuration key for your AdapterManager needs to be renamed -- perhaps something like "db_adapter_manager" or "db_multi".

after the proposal from ralph i tried to solve the dependencies to the ServiceManager package...
The tow last commits of this branch are one Version.
Currently i only have this case in for databases. Theoretically this comes for every class you want init smartly...
So I'm not sure what way is the right:

• do it only for DB ( with the current proposal )
• do it with a abstract way
• or do nothing and everyone do it self ( but ugly )

@weierophinney
thanks i will patch this ;)

Is this available for end users (configuring/using multiple databases)? If not could you please point me in the right direction for an intermediate solution?

@ClemensSahs do you have time to do this in the next 1-2 weeks? If not, I need to change the milestone.

@zensys This is a pull request adding the feature; it's not available currently in the master repository.

Do you have any additional comments here? If not, do you mind if I take this for inclusion in 2.1, my only change is that it resides in the Zend\Mvc\Service namespace as it has dependencies on Zend\Mvc conventions and also promotes a configuration convention.

@weierophinney
currently i have time agin, sry for be so far away

@ralphschindler yes i will change some think and will implement unit tests

for all
i will try this changes to this Weekend

@ClemensSahs Feature freeze is in a couple days. I'm going to remove the milestone. If you get it done by then, I'll re-assign it to 2.1.

@weierophinney
I think I'm finished. if no one has if objections or improvements.

@zensys
no it is finished, I have update the description. So its easy to write a Doc

I'm wondering if DbAdapterManager can just extend off of Zend\ServiceManager\AbstractPluginManager. That way you don't have to recreate so much of the service locator functions. The DbAdapterManagerFactory can then just be an extension of Zend\Mvc\Service\AbstractPluginManagerFactory.

The DbAdapterManager should be added to the list of configurable service managers in Zend\Mvc\Service\ModuleManagerFactory. This way users can manage the db adapters just as they would any other service/plugin provider.

To implement the ServiceLocator has only one benefits. Add the ability to use ServiceKeys like aliase.
So if you have a "driver factory" you can use it, the same with a platform object.

I think a extention of AbstractPluginManager to much for this case.
Or I misunderstand your point?

Right, but extending the AbstractPluginManager gives you all that for free essentially. This way you can:

• add factories to define custom adapters
  • look up config and other stuff from within the factory
• use the built-in aliasing
• use invokables for custom drivers and platforms

and not have to reinvent a lot of the stuff you're doing in your manager.

Sounds nice but overstocked. The main benefit of my PR is a multi db alternative for Zend\Db\Adapter\AdapterServiceFactory if your improvements make it easy for End-User, then I'm vote for it too.

But I see currently only more complexity. Can you give me a example config for your version like the one in the description?

Sure:

class Module
{
    public function getConfig()
    {
        return array(
            'db_adapters' => array(
                'adapters' => array(
                    'module1' => array(
                        'driver' => 'pdo_mysql',
                        'username' => 'user',
                        'password' => 'pass',
                    ),
                ),
                'aliases' => array(
                    'default' => 'module1',
                ),
                'factories' => array(
                    'module2' => function ()
                    {
                        return new Adapter($driver, $platform);
                    },
                ),
            ),
        );
    }
}

class IndexController
{
    /** @var \Zend\Db\AdapterManager */
    protected $adapters;

    public function indexAction()
    {
        $adapter = $this->adapters->get('default');
    }
}

@radnan
here is a version with implement your improvements. Its a preview, currently I want move the building methods in to a separate factoring Class.
ClemensSahs@bcd7815

refactoring in progress for Unit-Test and Exceptions

PS: the methodes I mean

• getQueryResultPrototype
• getDriverObjectFromConfig
• getPlatformObjectFromConfig
• createFromAdapterConfig

any feedback?

@ClemensSahs I find your patch pretty interesting.
Since @EvanDotPro wrote the originaly factory in Zend\Db, I'd like to get his opinion on this too, also since he had a hand in ZfcUser, which consumes database adapters.

I'd like to humbly submit my take on the issue:

radnan@42245d4

@radnan
its looks nice ;)

but on this way we don't can customizes "plattform objects" and "result prototype"
Currently I miss this is a feature on your commit...

I am going to close this PR. The idea is good, but this particular implementation is not what needs to happen. Probably @radnan's implementation is closer, if he were to move it into the Zend\Mvc namespace. From there I think we can open an new PR when that one is ready.